It used to be that the Internet and wide area communications networks were not generally expected to deliver data in a time critical or even very timely manner. Users generally expected a few seconds or even a few minutes of delay as data traversed unpredictable routing paths through large networks. Such lack of timeliness was accepted for many types of data transfers including for example email and computer files.
Now, however, there is ever increasing demand for “real time applications” such as voice and video. People want to watch streaming video of their favorite TV shows, movies and shared home movie site downloads on their cell phones and other portable web-enabled appliances. Teenagers want to voice chat and/or video chat with friends. More and more people now are using their Internet connections to make telephone calls. Countless businesses, public safety agencies and others are deploying some type of wireless or wired technology so the same communications network can carry both voice and data. So-called “Soft Phones” (software that allows a computing device to perform the functions of a telephone) are moving beyond the college dorm room and are on the road to becoming important enterprise applications and collaboration tools. Major telecommunications providers including large “telephone companies” are getting into the game by deploying increasing numbers of Internet Protocol based “telephone” switching stations and providing softphone solutions in addition to handsets. More traditional Internet Service providers are expanding their offerings to include Internet Multimedia Service (IMS) products providing a wide range of services including but not limited to Voice Over Internet Protocol (“VoIP”).
Such real time applications are destined to become ubiquitous. As users increase their use of real time applications, it is foreseeable that usage will expand to a wide variety of networks and data communications infrastructures including for example remote access from cable modems, DSL, 802.11 (WIFI) hotspots, WiMax and next-generation cellular telephone systems. Delivery platforms could include all sorts of devices such as but not limited to desktop computers, laptop computers, and portable devices such as personal data assistants, cell phones and any of a variety of other computing and/or web-based appliances.
Existing conventional technologies such as Voice Over Internet Protocol (VOIP) provide functionality that allows voice or other streaming data to be carried over conventional Internet Protocol (IP) connections. Such technology has become widely adopted in a variety of contexts. However, significant challenges remain. For example, real time applications are generally more sensitive to network vagarities and constrained network bandwidth than general network applications or traditional “data” applications. Much work has been done to try to solve these challenges, but the problems have not yet been fully addressed. Sensitivity to the underlying network, diversity of environments, the desire to roam, security issues and the convenience of traversing firewalls are all factors to consider when supporting real time applications within and outside the enterprise.
One example approach to efficiently carrying real time application information over IP networks has been termed “Next Generation Networking” (NGN) spearheaded by the International Telecommunications Union “Next Generation Network Global Standards Initiative”, ETSI and others. One idea behind this approach is to label each type of data packet with the type of information it contains (e.g., data, voice, video, audio, etc.) and handle each packet differently for Quality of Service (QOS) and other purposes. While NGN shows promise, it is not clear right now how such architectures can be made compatible with existing security architectures protecting privacy and data integrity. A significant challenge therefore relates to how to use Voice Over IP and other real time applications to provide “unified communications” (e.g., voice, video, instant messaging, collaboration, other) in conjunction with existing or new Virtual Private Network (VPN) architectures—especially VPNs that can provide mobility and allow mobile and portable users to roam between networks and subnetworks.
Meanwhile, Virtual Private Networks (VPNs) have all but replaced private wirelines of just a few years ago. Many enterprises have come to rely on VPNs to protect their communications from eavesdroppers and hackers. Generally speaking, a VPN uses encryption to construct a secure “tunnel” through a network. The tunnel provides end-to-end protection for the information flowing through the tunnel. Only the devices (encrypting/decrypting engines) at each end of the tunnel can access information flowing within the tunnel. Intermediate devices generally have no access because they cannot break through the tunnel's encrypted walls. This is good from a secrecy standpoint but can cause significant problems for devices that are attempting to handle data packets differently based on packet contents. Since most VPNs use encryption to intentionally try to make all data packets unintelligible to all network nodes except the intended recipient's decryption engine at the other end of the tunnel, intermediate nodes attempting to handle or process packets differently based on packet marking and/or contents will generally fail. This can present significant challenges to Quality of Service (QOS), carrier compression, call policy, error recovery/resiliency, low jitter, low latency, browser mobility policies, peer-to-peer mode and other issues.
For example, the performance of virtual private networks would be enhanced if they can take advantage of advanced compression techniques within carrier networks. It would be helpful if a VPN were capable of identifying VoIP and other real time data flows and assign associated priorities to take advantage of the quality of service in the underlying infrastructure as well as within the tunnel itself. In certain contexts, a VPN could also be a convenient place to implement call policies such as caller ID, valid networks, permitted callers and time of day. A VPN could be able to manage roaming with real time data flows. A VPN also could become a convenient way for enterprises to manage secure remote peer to peer communication. A VPN is a convenient way to traverse firewalls and NATS with real time and SIP based applications. In addition, the VPN is in an excellent position to enforce management of these applications. VPNs can also be a convenient method for managing web browsing activities.
Despite such potential advantages, existing VPNs are generally not particularly good at handling real time applications. Jitter and latency tend to be real problems. Latency can be thought of as the amount of time a communication is delayed. Jitter can be thought of as variance in arrival time for different packets or other received communication units. Latency of up to 300 or even 400 milliseconds can be tolerated for most real time applications (even voice communication), but in modern networks it is very possible that different packets will take different paths to get from point A to point B, thereby creating a substantial amount of jitter. If packets arrive at widely differing arrival times, a receiver may need to temporarily store (“buffer”) the received packets (thereby increasing latency for all received packets) to even out arrival time variances. The quality of real time applications can suffer noticeably if buffering is inadequate. For example, a VPN running full duplex VOIP or other real time data flows should preferably not increase jitter or add to network latencies and should preferably not cause error bursts or bursts of outdated packets, but should instead reduce packet errors and error bursts whenever possible. But issues can arise that relate to ways communications systems handle transferring data packets between endpoints in the presence of data and packet loss.
For example, conventional TCP protocols when used with conventional VPNs can often cause severe jitter problems. The so-called “ARQ” (automatic repeat request) error control such as currently used by the IEFT standard TCP protocol involves the sender retransmitting lost packets when the receiver indicates that it has not received all intended data. Such ARQ techniques provide high reliability but can in some cases increase both latency and jitter.
Since IPSEC and other existing security agents are generally not bound by TCP constraints and can use UDP instead, some or many of these problems can be overcome by foregoing TCP acknowledgements and associated guaranteed reliable delivery. However, IPSEC in the past has not generally provided mobility. Every time a VPN end node changes address in such systems, previous versions of IPSEC will generally lose the connection. An industry consortium is attempting to enhance IPSEC with a 2.0 version that will allow renegotiation of end node addresses. But most IPSEC encapsulation requires a substantial amount of overhead (e.g., 32 bytes of overhead plus padding for each data packet sent). The extra overhead can sometimes cause problems in handling and communicating real time applications.
One known method, termed “packet loss concealment”, involves using techniques such as interpolation and/or reconstruction from the last known good reception of data to hide lost data from applications. A technique that can be used to effect packet loss concealment is forward error correction (FEC) for packet erasure purposes.
Shannon demonstrated in the late 1940's that noise on a communications channel does not necessarily prevent error-free communications. Shannon theorized that error codes could provide error-free communications even in the presence of noise, and that noise thus reduces the channel capacity but not necessarily error rate. By the early 1980's, the techniques had progressed sufficiently so that inexpensive computing devices could be programmed to provide error correction coding for now-ubiquitous Compact Disc players. See for example Jacobsmeyer, “Introduction to Error-Control Coding” (Pericle Communications 2004).
Generally speaking, forward error correction involves adding redundancy in such a way that lost bits, in the case of a bit stream, or lost packets, in the case of datagram stream, may be recovered by the receiver without requiring the sender to retransmit data (or so that the receiver can tell packet integrity has been lost).
Certain FEC codes are sometimes denoted as (“n,k”) codes, where n-k is the number of parity check packets, n is the total number of packets in a block and k is the number of original data packets to be transmitted from the sender to the receiver. For example, letting n=8 and k=5 means sending 8 packets consisting of 5 data packets and 3 parity check packets. The parity check packets are used to correct and recover lost packets in the event any 3 of the 5 data packets are lost. Such a code is called a “k/n=5/8 rate” code to indicate it takes a total of 8 packets to send the intended 5 data packets. Note that in this instance, the additional 3 packets are “overhead” used to provide a zero error rate. Sending these additional packets thus reduces the capacity of the communications channel while nevertheless providing error-free transmission, just as Shannon postulated.
IETF RFC 3453 “The Use of Forward Error Correction (FEC) in Reliable Multicast” (2002) proposed to use a block (n, k) FEC code for certain network transmissions such as reliable IP multicast transmissions. This RFC 3453 describes encoding some number k of source symbols into n encoding symbols n>k, such that any k encoding symbols can be used to recreate an exact copy of the original k source symbols. A popular example of these types of codes is the class of Reed-Solomon codes, which are based on algebraic methods using finite fields. Generally, in practice, the values of k and n are kept small (for example below 256) for such FEC codes as large values can make encoding and decoding prohibitively expensive for certain applications. As many objects are longer than k symbols for reasonable values of k and the symbol length (e.g. larger than 16 kilobyte for k=16 using 1 kilobyte symbols), they are often divided into a number of source blocks. Each source block consists of some number k of source symbols, where k may vary between different source blocks. The FEC encoder is used to encode a k-symbol source block into a n encoding symbol encoding block, where the number n of encoding symbols in the encoding block may vary for each source block. For a receiver to completely recover the object, for each source block consisting of k source symbols, k distinct encoding symbols (i.e., with different encoding symbol IDs) are received from the corresponding encoding block. For some encoding blocks, more encoding symbols may be received than there are source symbols in the corresponding source block, in which case the excess encoding symbols are discarded.
These and other FEC error coding techniques are straightforward to implement. However, as mentioned above, existing FEC techniques can add overhead to the network when least desired. Packet loss is often caused by congestion. Sending multiple copies of a single packet or additional parity codes increases congestion proportionately. This reduces bandwidth efficiency, thus reducing end to end performance (speed) for other applications attempting to share the network. Furthermore, FEC does not necessarily inherently scale, so adding more robustness can cause an exponential increase in bandwidth requirements.
Decreased latency is another area of further potential improvement when attempting to communicate real time information. In the absence of dropped packets, it is desirable for any forward error correction technique to add minimal (approximating zero) additional latency and jitter to packet transfers over and above the latency and jitter of UDP packet transfers not employing forward error correction. It is also desirable for any FEC techniques to add little additional overhead, thereby minimizing network overhead for small and large packets. Attention should also be paid to dynamic characteristics. Bandwidth (BW) efficiency and burst error protection levels should be easily adjusted to accommodate varying levels of BW utilization, packet loss, latency and jitter requirements.
It would also be desirable to provide a solution that is scalable so that it can correct lost packets for any (n−k) out of n packets. Some examples of desired FEC rates (“values of k/n”) may be for example 2/4, 3/5, 5/7, 5/10, 125/150, 32/39 etc. For a 32/39 code, for example, one might want to correct any 7 packets out of 32. Such a code hypothetically could be used for example under existing protocol layers to augment ARQ capability when a window of 32 packets is employed. But for real time applications, a hypothetical 3/5 code may be more appropriate where latency and jitter levels should be minimized to maintain acceptable real time performance.
It would also be desirable to provide a programmatic solution for detecting different types of traffic so that real time optimizations such as but not limited to FEC can be selectively applied. As mentioned above, typical virtual private networks use encryption to prevent eavesdroppers from accessing the information flowing through the secure tunnel. These same encryption techniques can prevent routers and other network appliances from looking inside the secure tunnel to ascertain whether information flowing through it is real time information (to which real time optimizations might be applied) or data (which might require 100% or near 100% reliability). Sometimes in the past, network administrators have tried to solve this problem by allocating different ports to different types of traffic. For example, real time applications might be told to use certain ports whereas data applications might be directed to use certain other ports. However, there is no widely adopted standard for port allocation, and therefore different applications often use different ports for different purposes. Typically in the past, it has been up to a network administrator to try and figure out which applications within an enterprise are using which ports for which traffic types.
One common solution is to maintain a large database of applications and associated port allocation usage. It would be desirable to provide a flexible solution that does not need to know in advance which port a particular application will use for particular types of traffic and to nevertheless be capable of adapting to provide real time optimizations such as FEC to real time data so that the same techniques that are successfully used to manage the reliability of for example TCP data packets are not applied to real time UDP packets where they will potentially, depending upon network conditions and other factors, undesirably increase latency and jitter.
Furthermore, while real time applications can benefit from forward error correction and other techniques that increase the reliability of packet delivery, it may not be essential to the end user experience that such techniques always be applied no matter what network conditions prevail. There are tradeoffs between timeliness and error-free communication that a well-designed system should preferably be able to dynamically take into account. This becomes especially important within the context of a communications system supporting mobile and portable devices that can roam between networks and subnetworks. As user devices roam, noise, bandwidth and congestion can change radically from moment to moment. Some past attempts at managing such traffic simply “break” under the stress of rapid changes in network conditions, causing undesirable user experiences including for example loss of an ongoing soft phone voice communication or “freezing” of real time media streams such as audio or video. It would be highly desirable for a system to be able to recognize and adapt to changing network conditions to dynamically throttle back on the amount of error correction and other techniques being applied to thereby deliver packets as reliably as possible with minimal added latency and jitter.
For example, it would be desirable to add error correction optimizations only or primarily when it does not affect bandwidth in a significantly adverse manner. When prevailing network conditions are significantly adversely impacting timeliness of packet delivery, then it may be desirable to dynamically decrease or even altogether eliminate error correction optimization. Such decisions concerning whether to apply error correction optimizations should preferably be made in a timely manner in a block by block (or packet by packet) basis so that error correction can be used when it is beneficial but is tuned based on the tradeoff between error correction and timeliness.
The exemplary illustrative non-limiting implementations described herein add optimization such as forward error correction when such optimizations do not substantially affect bandwidth or delivery timeliness in an adverse manner, but are capable of dynamically adapting to changing network conditions so that the optimizations are throttled back or even eliminated altogether when network conditions dynamically change in certain ways.
In one exemplary illustrative non-limiting implementation, each block of real time data packets transmits N and K parameters associated with forward error correction. This allows a mobile VPN application to tune or adjust the optimizations dynamically by changing N and K “on the fly.” Every K packet can be reviewed for packet size, and minimum and maximum packet size can be taken into account in determining the nature of the optimizations to be applied. In one exemplary illustrative non-limiting implementation, for example, forward error correction is continually turned on but in some cases (e.g., where bandwidth is limited so that it is important to decrease network overhead), the additional overhead associated with sending parity information can be eliminated simply by not sending parity. As long as the packets arrive in order, the mobile VPN can hand those received packets off to the application rapidly. If a packet gets dropped, the mobile VPN can attempt to correct it if parity information is available. If no parity information is available, then no correction is applied.
In one exemplary illustrative implementation, a small received packet buffer can be used to keep track of which packets have been received. In the case where degraded network conditions result in dropping of a packet (e.g., packet one was received, packet three was received, but packet two was not received), receipt of the first packet and a succeeding block or a receive time out may prompt the receiving agent to look at the list of received packets. If parity is available, the receiving agent can apply the parity using a conventional forward error correction process to reconstruct the packet that was dropped. If parity information is not available, then in a real time application context the receiving agent can immediately send the packets it has received to the application. Different actions can be performed if the packet is not real time data. This dynamic adjustment in favor of timeliness for real time applications can result in a more satisfying user experience at least because often in such applications timely delivery is more important than 100% accuracy.
In accordance with further exemplary illustrative non-limiting implementations, conventional data packets that should desirably be sent with near 100% reliability are usually transmitted using an “ARQ” protocol such as TCP, whereas real time packets (e.g., video, audio, instant messaging, collaboration, other) are typically sent using a non-acknowledgment protocol such as UDP. Using a resident low-level monitoring and/or routing function at or near the data transport or other layer of originating and receiving computing appliances, it is possible to determine irrespective of port assignment whether the packets being communicated are real time data or non-real time data by determining whether for example TCP or UDP is being used. Once the mobile VPN determines that UDP is being used by the application to send the information, it is desirable to first make sure that UDP data is amiable to the kind of optimizations that may improve reliability or whether such optimizations could cause more harm than good. One exemplary illustrative non-limiting dynamic optimization looks at packet size variance per K block. If that variance is greater than some value (which may be configurable in bytes for example), the mobile VPN can decide to forward blocks without parity and/or other enhancements (e.g., encryption). Most real time applications are already designed to handle dropped packets, so in such instances it may be more desirable to provide timely delivery without optimization when optimizing will do more harm than good.
The exemplary illustrative non-limiting implementation mobile VPN dynamically knows when to apply optimizations and when not to apply them. For example, the exemplary illustrative non-limiting mobile VPN can turn on optimizations based on an IP manager's configuration of an application and may turn off optimizations for a particular block of K packets based on variance and packet size. The exemplary illustrative non-limiting implementation is also capable of dynamically changing N and K parameters associated with forward error correction depending upon network conditions. For example, it is possible to dynamically adjust N to add or decrease the number of parity packets per block depending upon error rate. If a decoding peer indicates that decode errors are occurring, the exemplary illustrative non-limiting mobile VPN can increase N. If network bandwidth is so limited that increasing parity overhead will result in overall decreased performance, the exemplary illustrative non-limiting mobile VPN can maintain or even decrease N (the number of parity packets per block) to avoid compounding the prevailing network congestion problem—or in an extreme case, disable FEC altogether. Such dynamic resilience based on changing network conditions due to roaming or other factors results in significant improvements over prior techniques.
Still further improvements can be obtained by managing and shaping information traffic within a VPN tunnel. Such traffic management can be performed based for example on policy and/or priority criteria.
One exemplary illustrative non-limiting implementation allows policy to be shared between server and client, providing an agreement for use in accessing the VPN's encrypted tunnel. By thus exerting distributed, coordinated control at each of the tunnel ends, it is possible to overcome many of the challenges of VPN use without need to weaken end-to-end security.
Exemplary illustrative non-limiting implementations described herein provide a set of features allowing expediency to be favored over reliability when such would be advantageous. Exemplary illustrative non-limiting criteria for these modifications include for example:                Dynamic adjustment of optimizations including but not limited to forward error correction depending on network conditions, to adapt to roaming of a mobile end system between networks or subnetworks and/or other network events (e.g., change in network congestion level, available bandwidth or other factors).        Different optimizations applied to real time (e.g., voice and video) communications and non-real time (e.g., data delivery) communications in a “unified communication” mobile virtual private network so that for example non-real time data can be delivered with 100% or near 100% reliability whereas real time data can be delivered with degrees of error correction and other optimization processing that dynamically take timeliness and network conditions into account.        Add optimizations to real time data only or primarily when such optimizations do not adversely affect bandwidth and/or result in overall performance improvements depending upon network conditions.        Efficient ability to handle dropped parity and dropped packets.        Integration with policy management to give an IT manager or others an ability to specify whether a mobile virtual private network will apply optimizations on an application-by-application basis.        Adapt to ephemeral port allocation and eliminate the need for a network administrator to be involved in determining in detail which port(s) the application will use for such real time applications and/or to maintain a database correlating port assignments with different types of data flows.        Programmatically determine which port(s) are being used by a particular application and apply desired real time optimizations to the application by further distinguishing between real time and non-real time data based on protocol (e.g., an ARQ protocol such as TCP, or a non-ARQ protocol such as UDP).        Low level monitoring at or near the transport layer to automatically distinguish between different application protocol streams.        Dynamically monitor packet size variance to selectively and dynamically adjust the degree of parity or other forward error correction overhead to thereby dynamically take network congestion and other factors into account, thereby maximizing the benefit of optimizations such as forward error correction, encryption etc. while minimizing their potential adverse impact on network overhead and timeliness.        Optimal use of a packet-based forward error correction algorithm by applying packet sized variance per k block.        Dynamically, automatically determining when (and whether) to reduce or turn off error correction or other optimizations based on packet size variance and/or other factors.        In an N/K forward error correction protocol (where N represents number of parity packets per block and K represents total number of packets, K>N), dynamically changing N based on packet size variance, observed decode error rate or other factors.        Gratuitously informing peers of observed decode error rates to allow peers to dynamically adjust forward error correction parameters.        Providing separate and distinct forward error correction (N, K) parameters for real time and non-real time packets coalesced into the same block, to allow different optimizations to be applied to different data types (keeping in mind that for forward error correction purposes, each data packet should be mutually exclusive).        Support for number of parity packets N−K>K.        Selective dynamic enabling/disabling of data coalescing depending on prevailing network conditions.        Dynamic tuning of optimization(s) to maintain acceptable real time data communication performance.        Side by side operation of guaranteed delivery and unreliable protocols within the same mobile VPN tunnel, with appropriate dynamic optimizations applied to teach data stream type.        Interaction between forward error correction and block encryption without compromising security.        With the help of an RPC layer, coalescing together real time data from different sources on a mobile end system (MES), targeted for the same or different destinations, into a single stream and forwarding the coalesced data to an intermediary server (MMS). The data may then be demultiplexed at the MMS back into multiple distinct streams and sent on to its ultimate destination. The reverse operation can happen for data destined for the MES.        Allowing multiplexing of multiple real time streams for maximum use of available bandwidth, by generating the maximum sized network frames possible. Since expediency is favored, a maximum number of RPC requests that can be coalesced into a single block or message may be imposed.        In addition to using AES or other stream cipher functionality for existing traffic, the exemplary illustrative non-limiting technology herein may use counter mode security meeting for example, FIPS 140-2 compliancy.        The exemplary illustrative non-limiting technology herein may employ a cumulative Quality of Service marking algorithm. As each RPC request is coalesced, the QoS marking with the highest magnitude can be preserved and transferred with the subsequent frame.        The exemplary illustrative non-limiting technology herein can be engineered to be transport independent and to allow the network point of presence (POP) or network infrastructure to change without affecting the flow of data except where physical boundary, policy or limitations of bandwidth apply.        Exemplary illustrative non-limiting frames have a predetermined type and header format to further increase efficiency and reduce protocol overhead        When the PDU for a given block or message is greater then the available MTU of the network medium, standard fragmentation and reassemble functions may be provided.        Semantics of unreliable data can be preserved by allowing RPC requests to be efficiently discarded.        To ensure that a single communications session does not boundlessly consume resources, the exemplary illustrative non-limiting technology herein may in one implementation employ a depth limited FIFO queue. If the maximum queue depth is reached, a head-end discard mechanism can efficiently flush stale data and accept the most recent request.        The exemplary illustrative non-limiting technology herein can consider the send and receive transmission paths separately and automatically tailor its operating parameters to provided optimum throughput. Based on hysteresis or other factors, it is possible to adjust such parameters as frame size (fragmentation threshold), number of frames per second (rate limiting), etc.        The exemplary illustrative non-limiting technology herein is preferably designed to be network fault tolerant. Since the expected usage can be in a wireless environment, temporary loss of network connectivity does not necessarily need to result in termination of the session.        The exemplary illustrative non-limiting technology herein may employ a frame sequencing scheme allowing the receiver to detect out of order reception and not wrap within a reasonable amount of time.        In the exemplary illustrative non-limiting implementation herein, sequence numbers need not be byte oriented, thereby allowing for a single sequence number to represent up to a maximum of, for example, 65535 octets of information including the header (i.e., frame size can be represented as a 16 bit value in the header in one exemplary illustrative non-limiting implementation).        The exemplary illustrative non-limiting implementation herein provides a balanced design, allowing either peer to migrate to a new point of presence.        In the exemplary illustrative non-limiting implementation, either side may establish a session to a peer.        Capable of providing data and real time support for streams of datagrams such as those of real time applications and traditional datagram applications such as NetBios.        Minimizing memory requirements for buffering and the like.        
In one particular exemplary illustrative non-limiting implementation, a Reed Solomon (RS) erasure code using Vandermond matrixes is employed to provide error correction capabilities for applications using receive datagram event and send datagram request remote procedure calls (RPCs). An RS block can be defined as a Reed Solomon Block of packets. Each block consists of N packets where K of the N packets are RPCs transmitted between Mobility mobile end systems (MES) and mobility servers, and (N−K) packets are parity derived from the K RPCs. The example protocol permits N values to range from 0 to 31. When N=0, FEC is considered disabled. K values are permitted to range from 0 to (N−1). Therefore, when N=1, K must be 0 so FEC is considered disabled for both N=0 and 1. Within the enabled ranges of N and K, all combinations of N and K are permitted.                The exemplary illustrative non-limiting implementation can include cases where N−K>K, the number of parity packets per block exceeds the number of data packets per block. This may be desired when running on networks with extreme conditions such as those experienced on wireless networks such as current 3G, CDMA technologies.        The exemplary illustrative non-limiting implementation provides a method to dynamically adjust N and K values within their configured maximum ranges dynamically by adjusting to network conditions.        The exemplary illustrative non-limiting implementation provides bandwidth optimizations and heuristics that detect flows which are inappropriate for fec encoding and bypass encoding on a per RS block basis because they would otherwise cause excessive bandwidth expansion on networks if encoding had occurred.        For performance reasons on highly scalable servers that may have 10s of 000s of transactions and packets to process per second, received and sent data packets are not, in one exemplary implementation, copied before they are provided to the encoder and decoder for processing. To avoid copies, a reference count exemplary illustrative non-limiting implementation is used to permit data packets to be delivered to more than one object at a time such as the receiving applications, decoders, networks and encoders.        Policy management, heuristics on the real time protocol RTP protocol, and the Session Initiation Protocol, SIP may be used on a per user, application, device, network, time of day, or any other supported trigger to define a flow that would benefit by having FEC enabled. The exemplary illustrative non-limiting real time protocol, RTP does not use well known ports for selecting flows. This makes it difficult for an IT manager or administrator to know in advance which ports to select for FEC. This problem is solved with an ability to identify flows using one of the aforementioned methods and selecting the UDP flows associated with that application as having access to the FEC service.        